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Reading the definition from the top, it is said to be an 
augmented grammar definition of the language METASYNTAX. The rule 
defining METASYNTAX indicates that a language definition starts 
with the string .AUGjSRAM, followed by an identifier (the name of 
the language), followed by a RULE. The next character of the rule 
METASYNTAX is an iteration operator. The dollar sign has the 
meaning "zero or more occurrences of the element..." Thus, after 
the mandatory RULE, zero or more additional RULEs may appear. 
Finally, the string .END terminates the language definition. 

The next rule defines a RULE as an identifier (the metavariable 
name), followed by the string ": = " , followed by an EXPRESSION. 

Then zero or more occurrences of an element may occur, where the 
element consists of the single character ")"•( vertical bar mean- 
ing "or") followed by an EXPRESSION. Note the use of parentheses 
to, form a group that can be treated as a single unit. The 

expression «< ••!« expression > 

portion of the rule allows a RULE to contain alternatives. An 
example is the NOUN rule of Fig. 1.1. 1-1, which is read "a NOUN 
consists of the word 'BOY', or the word 'GIRL 1 , or the word 'DOG', 
or the word- 1 CATJ ". Finally, the RULE is said to be terminated by 
a semicolon (the one in quotation marks) and the RULE rule, having 
been completed, is itself terminated (by a semicolon without quota- 
tion marks). Keep in mind that symbols in quotation marks represent 
terminal symbols in the language being defined (in this case 
METASYNTAX) , while symbols not in quotation marks have meaning in 
the language in which the definition is written. 
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An EXPRESSION consists of an ELEMENT followed by zero or more 
additional ELEMENTS. An ELEMENT is an identifier (used for meta- 
variable names)., a string (used for specific terminal symbols), 
or any of the specific symbols ".ID", ".STRING", ".LABEL," 

".TREE", ".NUM", or ".EMPTY". ".EMPTY" is a reference to the null 
character string, which represents a condition that, during pars- 
ing, is always satisfied. It is used when optional elements are 
involved. If, for example, one wished to define a number with or 
without preceding signs (unary operators) , the rule might take 
the form 

NUMBER «» ( I f .EMPTY ) ,NUM I 

which specifies that either "+", or nothing at all may precede 

the number itself. 

An additional alternative for ELEMENT (after ".EMPTY") is 

".PEEK" "<" .STRING 

which represents a look-ahead capability. The effect is to peek 
ahead at the next input symbol to determine whether it is a spec- 
ified string. The significance will be clearer when parsirtg is 
discussed in more detail. The final alternatives for ELEMENT 
represent a parenthesized expression and an iteration respectively. 
Finally, the definition of .METASYNTAX is terminated by the string 
".END". 

It is suggested that the serious reader consider this defini- 
tion of METASYNTAX as a grammar for the simple language of Fig. 

1.1. 1-1 and as a grammar for the language in which the definition 
of METASYNTAX is written. This familiarization will help consider- 
ably when the metalanguage is used later in the definition of PLANS. 
1-14 
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Fig \ 2.2-1 $RESOURCE Standard Data Structure 


' ^PROCESS 



2.2-2 $PR0CESS Standard Data Structure 



Fig. 2.2-3 


$OPSEQ Standard Data Structure 











ASCHEDULE 


("SPUTTABIE" I "NONSPUTTABli"! (VALUE) 


DESCRIPTORS 


) QUANTITY ( ) (PARAMETER! 


Fig. 2.2-6 $SCHEDULE Standard Data Structure 


Rev A 



$OOBSET. 


$JOBSET 


$JOBSET 



Fig. 2. 4.1-2 (oonal) 
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h 2.4.3 INTERVAL JJNION 

2. 4. 3.1 Purpose and Scope 

Given two standard intervals, this module constructs a 
standard interval that represents their union, in the sense of 
the sketch below. 

$ INTERVAL A 1 1 

$ INTERVAL B ) 1 

$UNI0N ) j 1 | 

2. 4. 3. 2 Modules Called 


None 



2 


2 


.4.3.3 Module Input 

$INTERVAL_A and $NTERVAL_B are standard intervals. 
.4.3.4 Module Output 

$UNI0N is a standard interval. 



• 

2. 4. 3-1 
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2. 4. 3. 5 Functional Block Diagram 



2. 4.3-2 







INTERVAL INTERSECTION 

2. 4. 4.1 Purpose and Scope 

Given two standard intervals, this module constructs a 
standard interval which represents their intersection, in the 
sense of the sketch below. 

$INTERVAL_A | 1 

$INTERVAL_B | : 1 

$INTERSECTION ( 1 

2. 4. 4. 2 Modules Called 
None 

2. 4. 4. 3 Module Input 

$INTERVAL_A and $INTERVAL_B are standard intervals. 

2. 4. 4. 4 Module Output 
$INTERSECTION is a standard interval. 


2. 4. 4-1 
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2. 4. A. 5 Functional Block Diagram 
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FIND MAXIMUM 


2. 4. 5.1 Purpose and Scope 

Given a set of numerical values (i.e., a node of a tree for 
which each of the next lower level subnodes is terminal and has 
a numerical value) , find the maximum (minimum) of the values and 
find the indices (i.e., the ordinal positions in the original 
set) of each of the subnodes for which the value equals the 
maximum (minimum) . 

2. 4. 5. 2 Modules Called 
(None) 

2. 4. 5. 3 Module Input 

$SET is a tree of the form shown in the sketch. Minimum 
required data structure is a tree with at least one subnode at 
the next lower level. 

$SET 

(X) 

(value) (value) (value) 

where each value is numeric. 

2. 4. 5. 4 Module Output 

MAXIMUM is an arithmetic variable whose value is the maximum 
of the values of $SET. 
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SINDICES is a tree of the form 


$INDICES 



(index) (index) 


where the indices are the ordinal positions in $SET of all nodes 
whose value equals maximum. 


2 . 4 . 5-2 
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4.6 FI ND_MI NI MUM 

2. 4. 6.1 Purpose and Scope 

Given a set of numerical values (i.e., a node of a tree for 
which each of the next lower level subnodes is terminal and has 
a numerical value) , find the minimum of the values and find the 
indices (i.e., the ordinal positions in the original set) of each 
of thd subnodes for which the value equals the maximum minimum. 

2. 4. 6. 2 Modules Called 
(None) 

2. 4. 6. 3 Module Input 

$SET is a tree of the form shown on the sketch with at least 
one subnode at the next lower level. 


$SET 



where each value is numeric. 

2. 4. 6. 4 Module Output 

MINIMUM is an arithmetic variable whose value is the minimum 
of the values of $SET. 


.2. 4. 6-1 



$ I NDICES is a tree of the form 


$ I NDI CES 



where the indices are the ordinal positions in $SET of all nodes 
whose value equals minimum. 
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CHECK_FOR_PROCESSJ)EFINITION 

2. 4. 7.1 Purpose and Scope 

This module checks that all processes or operations sequences 
specified in $OBJECTIVE are defined in $PR0CESS or $QPSEQ. These 
processes may be listed explicitly or contained in an operations 
sequence specified in $OBJECTIVES . If any processes are not ... 
included in $PR0CESS, such information as process duration and 
required resources are not defined. Since this condition pre- 
cludes successful execution of the problem, the missing processes 
should be identified. This module performs that identification 
function. 

2. 4. 7. 2 Modules Called 
None 

2. 4. 7. 3 Module Input 

Input to this module consists of $OBJECTIVES, $0PSEQ and 
$PR0CESS . The minimum required data structure from these Standard 
Data Structures is illustrated in Fig. 2. 4. 7. 3-1. 

2. 4. 7. 4 Module Output 

This module will output a tree structure, $MISSING, with the 
names of unfound processes *and operations sequences. If this tree 
is null, no missing definitions have been identified. 


2.4. 7-1 
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Note : Minimum (i.e. relevant) portion of required input Standard 

Data Structures is shown. In all trees, any additional 
. structure will be preserved. 


$OBJECTIVES 


ft 


ft 

ft 

ft 


OPSEQ 


(NAME) 
TYPE 

(value) 


SOPSEQ 




(OPSEQ 

NAME) 



(ELEMENT 

NAME) 



(value) 


$PR0CESS 


Fig. 2. 4. 7. 3-1 

Minimum Required Input Structures from Standard Data Structures for 
Module: CHECK FOR PROCESS DEFINITION 
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X>X) 



2 . 4 . 7. 5 


Functional Block Diagram 
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2. 4. 7-6 Typical Applications 

This module is useful for initial problem processing, which 
checks for logical errors or incomplete data. 


( 


2.4. 7-4 


2. 4. 8. 3 Module Input 


The input to this module consists of the trees, $OBJECTIVES, 
$0PSEQ, and $PR0CESS, defined previously, and the integer 
INI T I AL I D . The minimum required data structure from these stand- 
ard structures is shown in Fig- 2. 4. 8-1. I N I T I AL I D is the first 

integer to be used in constructing unique job identifiers within 
the module. 

2. 8. 4. 4 Module Output 

This module will return an output tree $J0BSET to the calling 

program. It will contain the REQUI RED RESOURCES information from 

$PR0CESS with any specific ASSOC IATED_RESOURCES information from 
$OBJECTIVES replacing the corresponding generic information in the 
REQUI RED_RESOURCES. Since it is permissable to specify specific 
resources in both $PR0CESS and $OBJECTIVES, this module will pro- 
duce an error message when inconsistent data are specified. The 

l 

structure of $J0BSET is shown in Fig. 2. 4. 8-2. 



Note : Minimum (i.e., relevant) portion of required input Standard Data 

Structures is shown. Any additional structure will be preserved 
in all trees. 


$OBJECTIVES 



OPSEQ 

(NAME) 

TYPE 


(VALUE) 



$0PSEQ $PR0CESS 



(VALUE) (VALUE) 


Fig. 2. 4. 8-1 

Minimum Required Input Structures from Standard Data Structures for Module 
Generation 
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2. 8. 4-5 Functional Block Diagram 



2 . 4 . 8-6 










SJOBSET 



("START" ("<" "<"J"=" ("START" (VALUE) 

| "END") |">" ">") | "END") 




(VALUE) (VALUE) (VALUE) (VALUE) 


Fig. 2. 4. 9-1 . 

Minimum Required. Input Structures from Standard Data Structures for Module: 

CHECK_EXTERNAL_TEMP_RELATIONS 


2. 4. 9-4 
Rev A 




2.4.10 CHECK I NTERNAL TEMP RELATIONS 

2.4.10.1 Purpose and Scope 

This module will determine the temporal relations specified 
for jobs in $J0BSET that are violated within a single partial 
schedule that has two or more jobs. 

Unlike CHECK EXTERNAL TEMP RELATIONS, this module will iden- 


tify all violations of temporal relations that exist within a 
singte tree containing several schedule units. The module will 
build an output tree containing a first-level node for each iden- 
tified violation of a temporal relation. Identifiers of the con- 
flicting jobs, the identifiers of the violated temporal relations 
and the interval of the violation will be recorded for each such 
node. 


2.4.10.2 Modules Called 


CHECK ELEMENTARY TEMP RELATION 


2.4.10.3 Module Input 

This module will be called with three arguments. There are two 
input arguments: $J0BSET and $SCHED. The structure of $J0BSET is 

identical to the structure output from the module GENERATE_JOBSET. 
The structure of $SCHED is that of the standard schedule unit. 

The minimum data structures required from the standard struc- 
tures $J0BSET and $SCHEDULE are shown on the following page. Note 
that in the minimum structure the fifth and sixth subnodes of a 
relation in the TEMPORAL_RELATIONS substructure are not mandatory 
in every case. 


2.4.10-1 



Note : Minimum (i.e., relevant) portion of the required input standard data 

structures is shown. In all trees, any additional structure will be 
preserved. 


’ $J0BSET 



$SCHED1 



(VALUE) (VALUE) 

Fig. 2.4.10-1 

Minimum Required Input Structures 

CHECK INTERNAL TEMP RELATIONS 


? 


from Standard Data Structures for Module: 


2.4.10-2 
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2.4.10.4 Module Output ^ 

This module will build and return an output tree 
structure shown below: 


with 


the 


OUTPUT DATA STRUCTURE 


JTEHPORALJIOLATWNS 



Each node of JTEMPORAL ^VIOLATIONS will correspond to a. violation of 
a temporal relation in $J0BSET (input) that appears internally in 


$SCHED (input),. 


2.4.10-3 
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2.4.10.5 Functional Block Diagram 
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2.4.11 CHECK JLEMENTARYJEMP 
RELATION 


2.4.11 CHECK ELEMENTARY_TEMP RELATION 

2.4.11.1 Purpose and Scope 

This module is elementary in the sense that it determines 
satisfaction or nonsatisfaction of a single input relationship 
involving the start or end times of two jobs for which specific 
start and end times have been assigned. The principal use of this 
module is to service higher level logic that is checking multiple 
temporal relations between or within sets of jobs. 

2.4.11.2 Modules Called 
None 

2.4.11.3 Module Input 

There are three input arguments to this module. These are 
$J0B1, $J0B2, and $RELATI0N. The structure of $J0B1 and $J0B2 is 
shown below: 


$J0B 



(VALUE) 


(VALUE) 



The structure of $RELATI0N is the structure of one of the sub- 
nodes of TEMPORAL_RELATIONS shown in the section on standard data 
structures. This module assumes that $ JOB 1 is the same job for 
which the structure TEMPORAL_RELATIONS is written and that $J0B2 
is the other job that is referred to in the fourth subnode of the 
special structure of $RELATI0N. Note that in illustrating the 
minimum required data structure for this information that the fifth 
and sixth subnodes for the structure $RELATI0N are not mandatory to 
specify temporal relationships in every case. 


2 . 4 . 11-2 


Note : The minimum (i.e., relevant) portion of the required input standard 

data structures is shown. In all trees, any additional structure will 
be preserved. 



("START" 
| "END") 


(»■<»« | «<« 
|">" j"7" 




("START" ["END") 


VALUE 


$RELATI0N 

OR Q predecessors 

(NAME) 


0 R Q SUCCESSORS 


Q* 

(NAME) 

Fig. 2.4.11-1 

Minimum Required Input Structures from Standard Data Structures for Module: 

CHECK ELEMENTARY TEMP RELATION 
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2.4.11.4 Module Output 


This module returns a tree SRESULT with two first level subnodes 
as shown below: • 



( YES J NO) (VALUE) 


The value returned for the LEFT_MINUS_RIGHT node is simply the 
algebraic result of subtracting the quantity on the right of the 
binary operator (_<, <, >) of the input TEMPORAL_RELATION 

from the quantity on the left. If the module is called with a 
PREDECESSOR or SUCCESSOR, this module assumes the following equiv- 
alent relations to compute the LEFT_MINUS_RIGHT value: 


GENERAL RELATION 



START 


END 


LEFT SIDE 


OF j ( JOB I D) | 


(CONSTANT) 


RIGHT SIDE - 


PREDECESSOR 

END OF J0B2 < START OF J0B1 
LEFT SIDE RIGHT SIDE 


SUCCESSOR 

START OF J0B2 > END OF JOB 1 
LEFT SIDE RIGHT SIDE 


2.4.11-4 



^ operator 

'SUCCESSOR', ' >'> > Yes , 

’>’ or '=' 


Place 'VES' 
as value of 
satisfied 
node. 

Place ’NO 1 

value of satisfied 

node. 


RETURN 
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2.4.12 NEXTSET 



2.4.12 


NEXTSET 


2.4.12.1 Purpose and Scope 

This module accepts an abstract description of item specific 
resource requirements associated with a specific job and, by re- 
ferring to information about the assignments already scheduled 
for the resources, determines the earliest possible time (within 
a designated interval) at which the resource requirements can be 
fulfilled. It generates all information required to actually place 
the job on the schedule but does not cause resource assignments 
to be written. The module also determines the time intervals 
during which the resource requirements are met using the same 
permutation of resources and time intervals for which any permuta- 
tion of available resources meets the requirements. 

2.4.12.2 Modules Called 

DURATION 

INTERVAL JJNION 

INTERVALJNTERSECTION 

2.4.12.3 Module Input 

$ABSTRACT is a tree structure that describes the job in terms 
of its general characteristics, resource requirements, and, if 
applicable, in terms of any user-designated specific resource 
allocations. Its structure is shown on the following page. 
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Except for the job, process, and resource intervals, the in- 
formation is exactly as used elsewhere for abstract process and 
job description. Specifically, the information is in the form 
generated by the module GENERATE_JOBSET . 

Since the absolute start and end times of the jobs, processes, 
and resource allocations are an output of this (and other) modules 
rather than an input, the intervals in this structure are rela- 
tive. The resource interval represents the start and . end times 
(relative to the start of the process) of a single resource al- 
location. These relative times may be positive, zero, or (very 
rarely) negative. 

The absolute start and end times of interest are specified in 
the argument list to limit the scope of assignments considered, 
and $RES0URCE is referenced to allow access to the resource as- 
signments. 

If for a given resource unit, the resource unit name is 
specified (i.e., LABEL($ABSTRACT.REQUIRED_RESOURCES(J) (K)) is not 
null, then it is assumed that the named resource unit is to be 
used. Regardless of the specification or nonspecification of the 
resource unit, the requirements (descriptors, quantity, etc.) 
still apply and must be satisfied, if possible, by NEXT. SET. 
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Note : The minimum (i.e., relevant) portion of the required input standard 

data structures is shown. In all trees, any additional structure 
will be preserved. 


$ABSTRACT 
O(J0B ID) 


| JOB 

I NTERVAL 


'REQUIRED RESOURCES 


•START 


(TYPE) 


(VALUE) 


(VALUE) 


(NAME) 


(NAME) 


Fig. 2.4.12-1 

Minimum Required Input Structures from Standard Data Structures for Module 

NEXTSET 
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OUTPUT DATA STRUCTURE 


$CONCRETE 
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2.4.12.4 Module Output 


The output of NEXTSET consists of two output trees, $C0NCRETE 
and $AVAILABLE_WINDOWS . $C0NCRETE, as shown below, describes a 
specific Execution of a job, with all times and resource alloca- 
tions fully specified in absolute terms at the earliest available 
opportunity within the specified window. $AVAILABLE_WINDOWS , 
also shown below, defines all of the available time intervals, 
within the specified window, for the set of resources correspond- 
ing to the set representing the earliest available time. It also 
defines the available time intervals if any permutation of ac- 
ceptable resources is considered. 


$AVAILABLE_WINDOWS 



(VALUE) (VALUE) 



2.4.13 RESOURCE PROFI LE 

2.4.13.1 Purpose and Scope 

In project scheduling the resources are assigned from a pool 
and, upon completion of the job, are returned to the pool of avail- 
able resources. Thus, the quantity of a given resource, available 
in the pool for a given time interval, is required to determine 
the advisability of scheduling a given job at a given time. Fur- 
ther, if sufficient resources are not available at the desired 
time, a contingency level of resources may be considered. This 
module determines the profile of available resources over a given 

time interval for both a "normal" and "contingency" level of re- 

% 

source. If contingency levels are not to be considered, they are 
set equal to the normal level. Certain functional characteristics 
of project scheduling also create the need to determine the usage 
of a pool assigned over a given interval (such as in attempts to 
level resource usage) . Therefore, this module also determines 
the profile of the assigned portion of the pool and defines the 
association of jobs that make up the usage profile.. 

2.4.13.2 Modules Called 
None. 

2.4.13.3 Module Input ~ - . - 

The input to this module will consist of the pooled resource 
type and name whose profile is to be generated, the time interval 
for which the profile is to be generated, and the $RES0URCE tree. 
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2.4.13.4 Module Output 


The output of this module will consist of a tree structure as 

shown in the sketch. The I N USE portion of the tree defines the 

quantity of the pooled resource assigned to a job for a given time 
interval. Therefore, the sum of the quantities for a given inter- 
val define the total I N USE resources for that interval. The span 

of intervals listed will be consistent with the input interval re- 
quested. The available portion of the tree defines the quantity 
of resource pool that is unassigned for both a normal and contin- 
gency mode of operation. These quantities are determined from 
the initial levels defined in $RES0URCE, the allocations recorded 
in the ASSIGNMENT portion of $RES0URCE, and the resources DELETED 
or GENERATED recorded in the ASSIGNMENT portion of $RES0URCE. 

$PR0FILE 
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2.4.13.5 Functional Block Diagram 
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This module assumes some conventions about the structure of 
the ASSIGNMENT node of any resource that is a pooled resource 
(i.e., for- which the node CLASS has a value 'POOLED'). A pooled 
resource that has explicit descriptors must contain a subnode of 
DESCRIPTORS for each partition of the pool. Those partitions that 
are being used in the assignment interval are distinguished from 
those not used in the interval by the appearance of the 'INITIAL' 
and the 'FINAL' nodes. Thus, the availability of a particular 
partition of a pool is precluded during the assignment interval 
only if that partition has a subnode of the 'DESCRIPTOR' node 
labeled 'INITIAL'. This convention is illustrated in the follow- 
ing structure: 



2.4.14-3 


Rev A 



The structure illustrates one assignment for the pooled re- 
source named CREWMEN and indicates that between 14 June and 28 
June five crewmen were assigned (indicated by the appearance of 
the INITIAL node) and 10 crewmen were not assigned. 

A slight generalization of the convention is required for pools 
that have overlapping assignments. The sketch illustrates the as- 
sumed structure of a portion of the ASSIGNMENT substructure for a 
pool of CREWMEN that has been separated into two partitions by 
previous assignments. Two assignments whose intervals overlap are 
shown . 
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ASSIGNMENT 




Note in the illustration that the availability of the crewmen . 
in the 10-man partition during the overlap of the assignment inter- 
vals (15 June through 20 June) cannot be determined correctly by 
merely noting the absence of the 'INITIAL' node in the first as- 
signment. This is because that partition is used in the second 
assignment. Therefore, the convention adopted requires that all 
assignments whose intervals include the availability time in ques- 
tion be considered in determineing the pool condition at that 
time. Note also that the ASSIGNMENT conventions for pooled re- 
sources permit the determination of descriptors by considering 
only the assignments whose intervals include the time in question; 
unlike the case for item-specific resources, there is no need to 
work progressively through all the descriptor changes from a set 
of initial descriptors to correctly determine the descriptors of 
pooled resource. (See the discussions in volume II on pooled and 
item-specific resources and the implication the corresponding 
conventions have on scheduling and unscheduling using time pro- 
gressive and time transcendent strategies) . 

This module builds a tree that displays for each conflict the 
set of resource pool descriptors that exist because of jobs already 
scheduled and those required to be added to the schedule. No in- 
formation on which previously assigned jobs caused the conflicts 
is included because the description of any pool is a result of the 
composite of all decisions on resource and job alternatives that 
have been made throughout development of the schedule. The most 
basic information needed to resolve the conflicts is simply what 
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descriptors exist and what descriptors are required. This infor- 
mation is provided by the output tree from this module. 

This module does not write or remove any assignments in 
$RES0URCE, i.e., $RES0URCE is returned unaltered. $RES0URCE is 
required by the module to assess the complete set of descriptors 
describing the pooled resources. 

2.4.14.2 Modules Called 
None 

2.4.14.3 Module Input 

This module is called with two arguments: $RES0URCE and 

$SCHED_UNIT. $RES0URCE has the general structure given in para- 
graph 2.4.14.1; $SCHED_UNIT has the general structure of a sched- 
ule unit shown in the following illustration. 

Note that in $SCHED_JJNIT the node labeled JOB_INTERVAL .START 
must contain the value of the assignment time for the job to be 
inserted. 
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$SCHED UNIT 
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2.4.14.4 Module Output 


This module returns a structure called $P00LED_RES0URCE_ 
CONFLICTS which contains information about conflicts that would 
result if $SCHED_UNIT were assigned at its specified time. The 
general structure of $P00LED_RES0URCE_C0NFLICTS is illustrated. 


$P00LED_RES0URCE_C0NFLI CTS 
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2.4.14.5 Functional Block Diagram 

Q Enter^ 



© 
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4.15 


DESCRIPTOR PROFILE 


2.4.15.1 Purpose and Scope 

This module is used to update the set of descriptors that 
apply to an item-specific resource, i.e., an individual, identifi- 
able resource that would correspond to the first subnode level of 
the resource "type" in the $RES0URCE tree. The update of descrip- 
tors will consist of an assignment or set of assignments that de- 
fine initial and final descriptors for each assignment. The 
original set of descriptors to be updated and their corresponding 
values will be supplied by the calling program. This could con- 
sist of reference to the resource descriptors in the $RES0URCE 
tree, a derived tree that has been maintaining the descriptors of 
that resource as a function of time, or a tree built by the call- 
ing program with specific (possibly artificial) descriptors. 

Any number of descriptive parameters may have been used in 
the resource assignments, but any one parameter will be assumed 
to contain only mutually exclusive values. For example, if the 
descriptive parameter, LOCATION is specified, values of DENVER, 
DALLAS, or DETROIT are obviously mutually exclusive. If, however,, 
the location were specified as DENVER and a process moved' the re-' = 
source to WAREHOUSE 3, this module would retain only the location 
WAREHOUSE 3 whether or not Warehouse 3 was located in Denver. 

2.4.15.2 Modules Called 

None. 
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2.4.15.3 Module Input 

Input consists of the item-specific resource to be considered, 
the original values of descriptors to be updated and the corre- 
sponding time, the assignments to be considered, and the interval 
of time that assignments are to be considered. The original de- 
scriptors and their values are defined in a tree structure as 
shown in the sketch. This format corresponds to the first level 
subnodes of the resource names in the $RES0URCE tree. 


SORIGINAL STATE 



The assignments to be considered would have a format corre- 
sponding to the subnode levels of the ASSIGNMENT node in the 
$RES0URCE tree as illustrated in the sketch. Any nodes, other 
than the time interval and descriptors (which are required) , will 
be retained for aiding traceability. 
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$ ASSIGNMENT 



2.4.15.4 Module Output 

. „ o « _ .. resource state" tree (shown) that 
The output consists of a 


lists the resource descriptors 


as a function of 


time. 


$resource_state 



2.4.15.5 Functional Block Diagram 
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2.4.16 UPDATE RESOURCE 

2.4.16.1 Purpose and Scope 

This module will update information in the data tree $RES0URCE 

for each resource assigned to a specific JOB I D in the structure 

$SCHEDULE. It provides a standard method of reflecting in 
$RES0URCE, the results of a scheduling decision. It creates a 
data structure $NEXTUNIT" that contains element (s) to be added to 
the chronologically ordered assignments of a specific $RES0URCE. 

( TYPE ).( NAME ) by calling the module WRITE_ASSIGNMENT . 

2.4.16.2 Modules Called 

WRITE_ASSIGNMENT 

2.4.16.3 Module Input 

Inputs consist of the standard data structures $SCHEDULE and 
$RES0URCE, that are shown in standard form on the following pages. 
The minimum relevant portions of the required input structures 
are shown on subsequent pages. 

2.4.16.4 Module Output 

During execution the module creates the data structure 
$NEXTUNIT. (See the following illustrations. After execution, 
the SRESOURCE tree will reflect the changes in assignments that 
result from the scheduling of all jobs in $SCHEDULE. 
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Note: Minimum (i.e., relevant) portion of required input Standard Data Structures 

is shown. In all trees, any additional structure will be preserved. 


$SCHEDULE 



$RES0URCE 


W(TYPE) 

Q(NAME) 

Fig. 2.4.16.4-2 

Minimum Required Input Structures from Standard data Structures 
for Module: UPDATE ^RESOURCE 
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OUTPUT DATA STRUCTURE 


SNEXTUNIT 
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2.4.16.5 Functional Block Diagram 
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2.4.17 WRI TE_ASS I GNMENT 

This module will add an element to the chronologicallly 
ordered assignments of the $RES0URCE tree for a specified resource 
name and type. Basis for the order is the resource interval start 
time. If start times are equal, the assignment with an earlier 
end time is listed first. If start and end times are equal, no 
distinction is made in the order.. 

The specific data written for an assignment can vary with the 
calling module. That is, dummy assignments may be made as a 
means of constraining resources in which case processes, prob- 
lem names, etc may be meaningless. However, selected resources 
for a given problem may. contain many parameters and descriptors 
that define the usage and provide traceability for later re- 
trieval. 

2.4.17.2 Modules Called 

None 

2.4.17.3 Module Input 

Inputs to this module consist of $ASS IGNMENT_UNIT , the as- 
signment node of $NEXTUNIT for which the assignment is to be 
written, and identif icaiton of the $RES0URCE subnode where the 
assignment is made. In the standard case, the entire substruc- 
ture of one of the third-level subnodes of $NEXTUN IT . RESOURCES 
becomes the substructure for one element of the standard data 
structure subnode $RES0URCE. (TYPE) . (NAME) .ASSIGNMENT that cor- 
responds to the resource type and name identified by 
$NEXTUNIT. RESOURCES. 
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MINIMUM REQUIRED INPUT STRUCTURES FROM STANDARD DATA STRUCTURES 
FOR MODULE: WRITE ASSIGNMENT 


Note: Minimum (i.e., relevant) portion of required input 

standard Data Structures is shown. In all trees, any 
additional structure will be preserved. 


• $RES0URCE 



(TYPE) 

(NAME) 

ASSIGNMENT 


$ASSIGNMENT UNIT 



INPUT DATA STRUCTURE 


$ASSIGNMENT UNIT 
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INPUT DATA STRUCTURE 


$UNSCHEDULE 
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2.4.18.4 Module Output 

Upon completion of this module, the assignment portion of 
$RES0URCE will be altered based on the contents of $UNSCHEDULE 

2.4.18.5 Functional Block Diagram 




Consider next resource name 


Locate assignments to be 
deleted based on intervals 
and descriptions in 
$UNSCHEDULE 


PRUNE assignment elements 


Have 

all resource names of 
this type been considered 


■ Have 

all resource types of 
this job been considered 


/ Have 
all jobs been 
considered 


Return 
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2.4.21 PROJECT_DE COMPOSER 

2.4.21.1 Purpose and Scope 

This module will identify all subprojects contained within a 
specified project. Frequently these subprojects, which are some- 
times apparent to the scheduler, are difficult to recognize in the 
complete network. Identification of the subprojects can signif- 
icantly reduce the computational effort required to schedule the 
entire project by enabling some of the scheduling analysis to be 
done separately for each subproject. For this reason the follow- 
ing analytical procedure is proposed for their detection. 

2.4.21.2 Modules Called 
None 

2.4.21.3 Module Input 

Critical path input data $J0BSET 

$J0BSET 
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2.4.21.4 Module Output 


Tree defining the unique subproject decomposition $J0BSET 
Subproject identifier (user supplied label) 

Member activity or event identifer 

Predecessor of activity or event identifer 


$J0BSET 



2.4.21.5 Functional Description 

In order to construct an algorithm for identifying "subproj ects" - 
this term must be precisely defined. A subproject is a subnetwork 
containing all the predecessors and successors of its member ac- 
tivities. (These, of course, do not include the events START and 
FINISH.) Recall that a network for scheduling purposes is a set r 
of activities and events denoted by nodes together . with all their 
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2.4.22 REDUNDANTPREDECESSORCHECKER • 

2.4.22.1 Purpose and Scope 

Given a set of activities and respective predecessor sets, 
this module eliminates any redundant predecessors. A predecessor 
is said to be redundant if it is not an immediate predecessor; 
that is, there is at least one intervening activity between the 
predecessor and its successor. As an example, suppose activity 
A is a predecessor of activity B , ■ and B is a predecessor of ac- 
tivity C. Then A is a redundant predecessor of C, while A and B 
are immediate predecessors of B and C, respectively. 

Expressing a project in terms of a collection of nonredundant 
predecessors serves two useful purpose: (1) it expedites con- 

siderably critical path calculations; (2) its facilities compre- 
hension of the precedence relations by representing the project 
in terms of the most logically concise precedence network pos- 
sible. 

2. 4. 2?. 2 Modules Called 

None 

2.4.22.3 Module Input 

Network "definition SJOBSET - including redundant precedessors 
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SJOBSET 



2.4.22.4 Module Output ' 

Network definition $J08SET - technologically ordered, exclud- 
ing redundant predecessors. 

2.4.22.5 Functional Description 

The most efficient redundant predessor elimination algorithm 
is a two-phase recursive procedure based on a technologically 
ordered job set. 

The first, or forward phase, recursively augments the predecessor 

© 

sets to introduce maximum redundancy beginning with the predecessor 
set of the first element in the technologically ordered job set. 

The second, or reverse phase, recursively decrements the maximally 
redundant predecessor sets to secure minimum redundancy beginning 
with the predecessor set of the last element in the technologically 
ordered job set. The major difficulty with this or any other 
algorithm designed to eliminate redundant predecessors is the 
excessive storage requirements. For a job set containing n ac- 

•7 

tivities up to n /2 memory cells can.be required to store the 
intermediate maximally redundant predecessors. 
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2.4.22.6 Functional Block Diagram 


REDUNDANT PREDECESSOR CHECKER 


Do \ 

/ any unexamined 

elements remain 

in technologically 

ordered job set on 

s forward pass 


Pick next unexamined 
element, i, in technologically 
ordered job set proceeding 
forward 


/ Do \ 

/any unexaminedS. 

elements remain ^ 
in technologically 
ordered set on > 
Njjackward pass/^ 


any unconsidered 
elements remain 
in predecessor set 
"N. of element , i / 
\ ? / 



Pick next unexamined 
element, i, in technologically 
ordered job set proceeding 
backward 




Pick next unconsidered 
element, j, in predecessor 
set of i 


/ Do \ 
'any uncons id erea^ 
elements remain 
in predecessor set 
\of element, i 


Augment predecessor 
set of i by predecessor 
set of j 


Pick next unconsidered 
element, j, in predecessor 
set of i 


Remove those elements from 
predecessor set of i that 
are in predecessor set of j 
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2. 4. 22.7 Typical Application 

The module can be applied wherever the most logically concise 
precedence network representation of a project is desired. This 
includes critical path calculation, automated heuristic schedul- 
ing, and manual precedence relation analysis. 

2.4.22.8 References 

Muth, John F. and Gerald L. Thompson: Industrial Scheduling , 

Prentice Hall Inc., Englewood Cliffs, New Jersey, 1963. 
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2.4.23 CR IT I CAL_PATH_CALCU L AT OR 

2.4.23.1 Purpose and Scope 

This module will calculate the critical path data for a proj- 
ect network. The variables computed are: Cl) early-start, late- 

start, early-f inish, and late-finish of each activity; (2) early 
occurrence and late occurrence of each event; and (3) total slack 
and free slack of each activity and event. 

A project that is defined by a collection of activities and 
events, their precedence constraints, and their durations must 
meet several other requirements to be amendable to critical path 
analysis: 

1) It must consist of a finite collection of well-defined activ- 
ities and events (with no unspecified alternatives) which, 
when completed, mark the end of the project. 

2) The activities may be started and stopped independently of 
each other within a given sequence. This requirement pre- 
cludes the analysis of continuous flow processes. 

3) The predecessor relationships among the activities and events 
must not contain cycles; that is there can be no predecessor 
chains implying that a job precedes itself. Thus a project 
is nonrepetitive. It is essentially a one-time effort such 
as a R&D task or a construction project. 

2.4.23.2 Modules Called 

ORDER_BY_PREDECESSORS 

FIND_MAXIMUM 

FIND_MINIMUM 
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2.4.23.4 Module Output 


Critical Path Output Data ($JOBSET) 


$J0BSET 
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2.4.23.5 Functional Description 

Critical path analysis is a powerful but simple technique 
for analyzing, planning, scheduling, and controlling complex proj- 
ects. In essence, the method provides a means of determining (1) 
which activities are "critical" in their effect upon total proj- 
ect duration, and (2) how to schedule all activities to meet mile- 
stone dates. 

Critical path analysis is based on the simple concept of pre- 
decessor/successor relationships between the activities and events 
defining the project network. A brief introduction to these fun- 
damental scheduling concepts is presented below. 

Let = {i,j,k, ...} be a set of activities and events that 
must be completed to finish a project. Let the symbol "<<" denote 
the basic immediate predecessor relation. Thus the notation i<<j 
is interpretated to mean that activity i must be completed before 
activity j can start. If s^. denotes the start of activity j and 
f denotes the finish of activity i, then the relationship i<<j 
is equivalent to the standard inequality s^f^. The set P^ = 


{ j : j << i } is said to be the immediate predecessor set of activity 
or event i. Similarly the set , £ ^ = {j ii<<j), denotes the im- 
mediate successor set of the activity or event i. 

A directed graph (network) is a useful topological representa- 
tion of a project, and can provide valuable insight into many 
scheduling problems. A summary of predecessor/successor relation- 
ships in terms of their network representation is given in Table 
1. More general temporal relationships can be easily included 
within this simple framework by adding artificial activities. 
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Table 2.4.23-1 Basic Precedence Relationship 



[ 1 ] 


[ 2 ] 


13] 


[ 4 ] 


Suppose now that every activity in the project is started as 
soon as possible, that is, as soon as all of its predecessors 
are finished. It is then possible to calculate the early start 
of each activity as 

l £ ?}- 

J i 

and the early finish of activity i is clearly 

f£ e . j 

. = s . + d , 
l i i 

where d. is the duration of the ith activity (d . = 0 for events), 
i i 

Similarly, the late finish for activity i is given by 



and the late start is 
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[ 5 ] 


For any activity, the* quantity 



is defined to be the total slack. The set of critical activities 
is then the subset of activities having minimum total slack. 

Another useful variable is free slack, . Free slack is 
defined as the amount by which an activity may be delayed with- 
out affecting any other activity. It is computed as 
[6] S f = mi 

j e 

The logic for the coordination of these calculations into 
an efficient computational procedure is given in the following 
block diagram. 
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Compute early start 
and early finish of 
next activity or event 
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y' Are n. 
there any 

activities or events with" 
uncomputed late 
.start and finish 
dates in technologically 
ordered set 


RETURN 


Select next (proceeding backward) 
activity or event from the 
technologically ordered set. 


/ Is next N 
activity or event 
an event whose 
late occurrence 
time is 
specified ^ 



Compute late finish 
and late start of 
next activity or event 



Compute total and free . 
slack for next activity. 
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2.4.24 PREDECESSOR SET I 

'2.4.24.1 Purpose and Scope 

Given a set of activities and their respective predecessor 
sets, this module will -form the respective successor sets. This 
inversion process is necessary for critical path computation. The 
project scheduling system assumes throughout that stating precedence 
relations in terms of predecessor sets is more natural than ex- 
pressing them as successor sets. For this reason the user is asked 
to define all subnetwork topology in terms of predecessor sets in 
the input data structure $J0BSET. 

2.4.24.2 Modules Called 
None 



) 
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2.4.24.3 Module Input 


Network definition ( $ J08SET ) — The substructures of the tree 
beginning at the nodes labeled SUCCESSORS are null upon input to 
the module. 


$J0BSET 



(JOB ID) 
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2.4.24.4 Module Output 

Redundant network definition ($J0BSET) - The substructures of 
the tree beginning at the nodes labeled SUCCESSORS are complete 
upon exit from the module. 


$J0BSET 
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2.4.24.5 Functional Description 

The logic of the inversion process frompredecessor sets is 
simple and direct. Each activity in the job set is considered 
in turn. Whenever a given activity is found in the predecessor 
set of another, the latter is included in the successor set of 
the former. When all of the predecessor sets of all of the jobs 
.have been examined., the collection of successor sets is complete. 
The following block diagram illustrates this straightforward yet 
efficient logic. 
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2.4.24.6 Functional Block Diagram 


PREDECESSOR SET INVERTER 
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2. A. 24. 7 Typical Application 

The module can be applied wherever successor sets rather than 
user input predecessor sets are required. This includes the mod- 
ules CRITICAL PATH CALCULATOR. 
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matter what its size, can be viewed as one comprehensible sum- 
marized network. Without this capability network analysis would 
be of little value to project scheduling.. 

The purpose of this module is then to convert a network, spec- 
ified in terms of a «jobset with its corresponding family of pre- 
decessor sets and durations, into a condensed network defined by 
its event and pseudo-activity set with its corresponding collection 
of predecessor sets and durations. 

2.4.25.2 Modules Called 

None 
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2.4.25.3 Module Input 


Critical Path Input Data ($J0BSET) 


$J0BSET 



(VALUE) (VALUE) 




2.4.25.4 Module Output 


Tree Defining the Condensed network 


$CONDENSED JOBSET 



2.4.25.5 Functional Description 

The problem of finding the critical delay between any pair 
of events is simply that of finding the longest directed path be- 
tween two nodes in a network not passing through any third node. 
Because the critical delays between all directly connected events 
are desired, the following approach suggests itself. Consider 
each event in turn. Step by step, examine all possible paths 
that terminate at the current event under analysis. All branches 
of any path must be investigated and for this reason a "pushdown" 
stack is useful in recalling which alternatives remain unexamined. 
A path is eliminated from further consideration when it reaches 
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an event or merges with some other path of greater length. Since 
the topology of the condensed networks are specified in terms of 
precedence sets rather than successor sets, it is convenient to 
proceed along the activity paths in reverse order to activity 
performance. 

The macrologic of the module requires a few further words of 
explanation. First, when an event is transferred from the input 
tree $J0BSET to the output tree $CONDENSED_JOBSET , . its predeces- 
sors are omitted and its duration is maintained at zero. Second, 
when candidate early start and finish times are computed, the 
calculations are performed as though the activities and events 
proceeded backward in time, This point of view is adopted to 
avoid the costly process of inverting the predecessor sets to 
obtain successor sets. Finally, the details of inserting a 
pseudo-activity into the output tree $CONDENSED_JOBSET are des- 
cribed. If pseudo-activity 1 represents a critical delay orig- 
inating at event i and terminating at event j, then the pseudo- 
activity should be listed as a predecessor of event j and event 
i should be listed as a predecessor of pseudo-activity i. The 
duration of the pseudo-activity is simply the critical delay be- 
tween events i and j (that is, the early start of event i computed 
with respect to event j). 
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2.4.25.6 Functional Block Diagram 


/ 
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c 



\ 
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2.4.26 CONDENSED_NETWORK_MERGER 

2.4.26.1 Purpose and Scope 

This module will merge two condensed subnetworks into a com- 
posite condensed network. This process is essential in merging 
subnetworks into a self-contained master network. 

2-4.26.2 Modules Called 
None 


2.4.26-1 



2.4.26.3 Module Input 

Critical path data for condensed subnetwork and condensed 
master subnetworks $CONDENSED_JOBSET 


$CONDENSED_JOBSET 



2.4.26.4 Module Output 

Critical path input data for merged network contained under 
master subnetworks node of $CONDENSED_JOBSET . 


2.4.26-2 


2.4.26.6 Functional Block Diagram 
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2.4.27 NET-WORK_ASSEMBLER 

2.4.27.1 Purpose and Scope 

Given a master subnetwork and its prescribed interfacing events, 
this module will assemble this subnetwork and all of its interfac- 
ing subnetworks into a master network.. This assembly capability 
facilitates the heuristic scheduling of any combination of sub- 
networks that may share common resources. The list of interfacing 
events need only be constructed to draw together all of the desired 
subnetworks . 

2.4.27.2 Modules Called 
None 


2.4.27-1 



2.4.27.3 Module Input 


1) Interface event definition ($INTERFACE) 


$ I NTERFACE 



(IDENTIFIER OF 
CONTAINING SUBNET) 


2) Subnetwork definitions, including master subnetwork ($J0BSET) 


tjoBsn 
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2.4.27.4 Module Output 


1) Heuristic processor input data under master subnetwork node 

of $J0BSET 

2) Component Subnetworks of Master Network ($SUBNET_SET ) 

A. Component subnet identifier 

$SUBNET_SET 



(COMPONENT 
SUBNET ID) 


O (COMPONENT 
SUBNET ID) 


(COMPONENT 
SUBNET ID) 


2.4.27.5 Functional Description 

The assembly of the master subnetwork and all of its inter- 
facing subnetworks into a master network is straightforward. A 
"pushdown" stack of interfacing subnetworks to be examined is 
initialized to contain the master subnetwork. The top element 
of the stack is analyzed for interfacing subnetworks by succes- 
sively examining each of its events for their presence in other 
unexamined subnetworks. Any such interfacing subnetworks found 
are added to the 'top of the stack. When all events in a subnet- 
work have been investigated it is added to the master network 
and removed from the unexamined stack. When the unexamined stack 
of interfacing networks is empty, the assembly process is complete. 
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2.4.27.6 Functional Block Diagram 
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2.4.28 CRIT ICAL PATH PROCESSOR 

2.4.28.1 Purpose and Scope 

Given a master subnetwork and its prescribed interfacing 
events, this module will 

1) Integrate the master subnetwork and all of its interfacing 
subnetworks into a condensed master network. 

2) Compute the early- and late-occurrence dates of all the in- 
terface events. 

3) Compute all critical-path data for the activities in the 
master subnetwork and all of its interfacing subnetworks. 

The objective of the module is to facilitate critical path 

calculations on networks too large to permit direct computations 
because of computer resource limitations in high-speed memory 
and execution time. 

2.4.28.2 Modules Called • 

NETWORKjCON DENSER 

CONDENSED_NETWORK_MERGER 
CRITICAL PATH CALCULATOR 


2.4.28.3 Module Input 


1) Interface Event Definitions ($INTERFACE) 


$INTERFACE 



(IDENTIFIER OF 
CONTAINING SUBNET) 


This data structure is illustrated in Fig. 2.4.28-1 for the 
subnetwork complex of Fig. 2.4.28-2 
2) Subnetwork Definitions, Including Master Subnetwork ($J0BSET) 


$J0BSET 



(JOB ID) 
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2.4.28.4 Module Output 

1) Identifiers of subnetworks that are components of total net- 
work (all subnetworks in $J0BSET may not be connected to total 
network) . 

$SUBNET SET 


'(SUBNET ID) (j(SUBNET ID) ^ ) (SUBNET ID) 
2) Critical Path Output Data (SJOBSET) 


$J0BSET 
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2.4.28.5 Functional Description 

This module has three basic objectives. The first objective, 
assembling the subnetworks into a 'condensed' self-contained master 
network, is the most involved and facilitates ready accomplishment 
of the remaining two. Basically, it involves determining all of 
the subnetworks to which the specified master subnetwork is con- 
nected by interface events. These subnetworks are condensed and 
then merged into a condensed master network. These steps can 
best be accomplished in ■ the recursive fashion. (See para 2.4.28.6.) 

The master condensed network is initialized as the condensed 
master subnetwork. Next a 'pushdown' stack o$ interfacing sub- 
networks is created and initialized as the master subnetwork. 

Then, the top subnetwork of the stack is condensed and examined 
for interfacing subnetworks. All unanalyzed subnetworks found 
are added to the stack. When the interface examination of a 
given subnetwork is completed, it is merged into the current con- 
densed master network. The merging process will be carried out 
by the module CONDENSED_NETWORK_fiERGER . When the 'pushdown' 
stack of unexamined interfacing subnetworks is finally emptied, 
a self-contained master condensed network has been assembled and 
is ready for critical-path analysis. 

The second objective of the module, calculation of the early 
and late occurrence dates of all the interfacing events, is ac- 
complished by applying the module CR IT I CAL_PATH_CALCULATOR to the 
condensed master network. To do so one need only construct the 
single tree $J0BSET, including the successor set substructure. 
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2.4.29 NETWORK EDITOR 

2.4.29.1 Purpose and Scope 

This module edits manually or automatically generated project 
scheduling precedence relations for logical inconsistencies. 

Four types of errors may occur in precedence data: 

1) The predecessor relationships may contain cycles; for example, 
job A is a predecessor of job B, B is a predecessor of C, 

•' and C is a predecessor of A. 

2) The list of predecessors for a job may include more than 
immediate predecessors; for example job A is a predecessor 
of B, B is a predecessor of C, and A as well as B are listed 
as predecessors of C. 

3) Some precedence relations may be overlooked. 

4) Some predence relations may be listed that are spurious. 

Errors of types (1) and (2) are inconsistencies in the data that 
can be detected by automated examination of the predecessor sets. 
Errors of types (3) and (4), however, appear to be legitimate 
data and, hence, cannot be discovered by computer procedures. 
Instead, manual checking (perhaps by a committee) is necessary 

to ensure that the predecessor relations are correctly reported. 

Errors of type (1) are fatal to the critical path analysis. 
Errors of type (2) , however, are not fatal and merely lengthen 
the execution of the critical path algorithm. For this reason 
the NETW0RK_EDIT0R has been divided into two separate editing 
procedures. The first, called ORDER_BY_PREDECESSORS , is manda- 
tory. All efficient CPM processors require the job set to be 


2.4.29-1 



arranged in a technological ordering (any job in the list precedes 
all of its successors) . This ordering is a useful byproduct of 
the cycle-checking routine. The second procedure, called the 
REDUNDANT_PREDECESSOR_CHECKER, is optional. Its use is, how- 
ever, recommended because, in addition to expediting the critical 
path processing, it generates the most logically concise prece- 
dence network possible. 

2.4.29.2 Modules Called 
ORDER _BY_PREDECESSORS 
REDUNDANT_PREDECESSOR_CHECKER 

2.4.29.3 Module Input 

1) Network definition $J0BSET - unedited version 

2) Redundant-predecessor-elimination option indicator (SIMPLIFY) 


$J0BSET 
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2.4.29.4 Module Output 

1) Network definition $J0BSET - edited version 

2) Cycle-containing subset of activities or events $CYCLE_SET 

$CYCLE SET 

(JOB ID) 

2.4.29.5 Functional Description 

The module NETW0RK_EDIT0R serves primarily as a coordinator 
of the two editing modules ORDER_BY_PREDECESSORS and REDUNDANT_ 
PREDECESSOR_CHECKER. This module is intended to prevent the 
user from attempting to use REDUNDANT__PREDECESSOR_CHECKER 
without first having called ORDER_BY_PREDECESSORS to place the 
second level subnodes of $J0BSET in a technological ordering. 
The user may opt not to eliminate redundant predecessors by 
setting the flag SIMPLIFY. 
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2.4.29.6 Functional Block Diagram 
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descriptors at the assignment time, the incompatibilities that 
are identified for times after the assignment time are those 
that result assuming compatibility between the scheduled resource 
descriptors, and the required descriptors for the job to be in- 
serted. This is illustrated below. 

Time 

I 7^ A A * 

^ Scheduled Job to be Scheduled 

Job 1 Inserted Job 2 



Incompatibility Incompatibility 

2.4.30.2 Modules Called 

DESCRIPT0R_PR0FILE 

2.4.30.3 Module Input 

This module is called with two input arguments. They are 
$RES0URCE and $SCHEDULE_UNIT. $RES0URCE has the general structure 
given in Section 2.2 and must contain initial descriptors at a ~ 
reference time and all assignment and descriptor changes that 
are to be considered after that time. This information is re- 
quired by this module so that it can call DESCRIPTOR_PROFILE . 
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2.4.30.4 Module Output 


This module returns a structure called $DESCRIPTOR_CONFLICTS , 
which contains information about the conflicts that would result 
if $SCHEDJJNIT were assigned at its specified time. The general 
structure of $DESCRIPTOR_CONFLICTS is shown below: 


$DESCRIPTOR_CONFLICTS 



Each first-level subnode represents a resource status conflict 
that would result from the assignment of $SCHED_UNIT at the 
specified time. 
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$SCHED__UNIT has the -general structure of a schedule unit 
shown below : 


$SCHED_UNIT 



Note that in $SCHED_UNIT, the JOBINTERVAL .START must 
contain the assignment time for the job to be inserted. 


\ 
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2.4.30.5 Functional Block. Diagram 



















2.4.31 ORDER_BY_PREDECESSORS 

2.4.31.1 Purpose and Scope 

Given a set of activities and events and their respective 
predecessor sets, this module either places them in a technologi- 
cal order if one exists or identifies a subset of the activities 
containing a cycle. A technological ordering of the events and 
activities means an ordering such that any activity or event is 
preceded by all of its predecessors or equivalently followed by 
all of its successors. A cycle, on the. other hand, is a chain 
of predecessor-successor related activities or events implying 
that some event or activity is a predecessor of itself. Such an 
activity or event could never be scheduled because one of its 
predecessors, namely itself, could never be completed beforehand. 
Hence, the presence of cycles in a precedence network precludes 
any scheduling or critical path analyses. 

2.4.31.2 Modules Called 
None 


2. 4; 31-1 



2.4.31.3 Module Input 


Network definition ($J0BSET) - activities or events (first 
level subnodes) are not technologically ordered. 


$J0BLIST 



(JOB ID) 
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2.4.31.4 Module Output 


1) Network definition ($J0BSET) - activities or events (second- 
level subnodes) are technologically ordered. 

2) Subset of jobs containing cycles (if any exist) ( $CYCLE SET) 

$CYCLE_SET 

(JOB 

2.4.31.5 Functional Description 

It can be shown that the activities and events of a project 
can be technologically ordered if, and only if, the precedence 
relations contain no cycles. It must be noted, however, that if 
cycles are absent, the technological ordering is by no means 
unique. The particular ordering produced by this module results 
from inductively "scheduling" in cycles all those activities or 
events whose predecessors are "scheduled." Eventually a cycle 
arises where there are no activities or events with all of their 
predecessors "scheduled." If some activities or events remain 
unscheduled, they contain a cycle. A more precise description 
of the logic of the module is provided in the functional block 
diagram. 
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2.4.31.6 Functional Block Diagram 



2.4.31-4 






limits of their residual slack to produce heuristically the most 
level resource-loaded schedule. 

2.4.32.2 Modules Called 
None 

2.4.32.3 Module Input 

1) Network, Critical Path Data and Activity or Event Definitions 

$J0BSET 


2.4.32-3 



(SUBNET ID) 


o 
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2) Resource Definitions ( $P ROF I LES ) 


5PR0FILES 
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2.4.32.4 Module Output 


1) Resulting Heuristic Schedule ($SCHEDULE) 


$SCHEDULE 



2) Revised Resource Profile Including Usage ( $P ROF I LIES ) 


$PR0FILES 
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Fig. 2.4.32-2 
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Fig. 2.4.32-2 

trace of the Execution of the RES0URCE_ALL0CAT0R Algorithm on the Constrained-Resource 
Problem Shorn in Fig. 2. 4. ,32-1 , Using Contingency Resource Thresholds on the First and 
Third Resources } Respectively 





Utilization of Utilization of Utilization of 



Fig. 2.4.32-4 

Minimum Duration Solution to Constrained-Resource Problem 
Using No Resource Contingency Levels 
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The optimal schedule requires two more days than the contingency- 
resource schedule . Which schedule is suprior depends on the 
availability of supplemental resource units; that is, on the 
"hardness" of the resource constraints. It is obvious that the 
optimal schedule is superior to the 25-day RESOURCE_ALLOCATOR 
schedule generated ass umin g no resource contingency levels, as 
shown in Fig. 2.4.32-5. Thus, it is apparent that the simple 
priority rule scheduling of the RES0URCE_ALL0CAT0R , which is in 
force when no resource thresholds are present, is greatly enhanced 
by the modifying heuristic that invokes contingency resources when 
an activity's late-start date is slipped. Finally, it should be 
noted that by executing a series of parametric funs with varying 
resource contingency thresholds, a thorough analysis of the 
tradeoff between project duration and resource availability can 
be made . 

2.4.32.8 References 

Davis, Edward W. and Heidom, George E. , "An Algorithm for Optimal 
Project Scheduling under Multiple Resource Constraints", Manage- 
ment Science, August 1971. 

Davis, Edward W., "Networks: Resource Allocation", Journal of 

Industrial Engineering, April 1974. 

Burraan, P. J. : Precedence Networks, for Project Planning and Con- 

trol. McGraw Hill, London, 1972. 
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2.4.33 RESOURCELEVELER 

2.4.33.1 Purpose and Scope 

In many project scheduling situations, the pattern of resource 
utilization is often more important than the quantity of resources 
used. For example, a resource feasible schedule that results in 
rapidly changing resource requirements is clearly undesirable from 
the project control standpoint. In these situations it is useful 
to perform resource leveling in order to reduce resource profile 
fluctuations. 

Conceptually, a resource utilization profile is level when the 
actual quantity of resource used in each time period is constant. 
Unfortunately, it is not generally possible to maintain perfectly 
level profiles and simultaneously satisfy all of the scheduling 
constraints. As a consequence, some fluctuations will inevitably 
remain in the resource profiles. The purpose of this module is 
then to minimize these remaining resource variations. This is 
accomplished by heuristically minimizing the sum of the squares 
of the resources over time, subject to the network, resource 
availability, and activity completion constraints. 

This module is applicable to the general class of project 
scheduling problems that includes multiple resources with time 
varying pool levels. 

2.4.33.2 Modules. Called 

None. 

2.4.33-1 
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2.4.33.3 Module Input 


1) Nominal Schedule ($SCHEDULE) 


$SCHEDULE 



(VALUE) (VALUE) 


2) Nominal Resource Profile ( $ P RO FILES) 


$PR0FILES 
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Fig, 2.4.33-2 Time-Varying Resource Variables 
This module can also be easily modified to solve the resource 
profile shaping problem. This can be accomplished by minimizing 
the square of the differences between actual and desired resource 
profiles . 
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2.4.33.6 Functional Block Diagram . 
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Ingenuity. Furthermore, questions that arise in modeling the 
project as a precedence network, frequently shed light on the 
entire scheduling problem. 

Burman (Burman, 72) has suggested a sophistication of the 
ordinary precedence network that would permit the simple repre- 
sentation of all temporal relations among activities and events. 
Indeed, a somewhat more involved critical path algorithm can be 
developed to generate critical path data for his sophisticated 
networks. Unfortunately, however, the new networks hopelessly 
complicate any heuristic scheduling process. As is so often the 
case in problem solving, it is far easier to generalize a problem 
than to solve it. 

Basically, what Burman has done is to identify a new type of 
successor — the closely-continuous successor. Such a successor must 
begin at the instant of completion of its predecessor. To see 
how this new concept facilitates the simulation of general temporal 
relations, consider the following examples. Consider the most 
difficult case of two activities whose respective start and finish 
are constrained to differ by a fixed time interval with the suc- 
cessor activity having an ordinary second predecessor as shown in 
Fig. 2.4.34-1. " ' ' 
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Fig. 2.4.34-1 

Sample Representation of a General Temporal Relation Using 
Closely -Continuous Successors 

To represent this temporal relation in terms of closely- 
continuous successors one has only to introduce a single dummy 
activity D requiring no resources of duration equal to the fixed 
intervale length "a." Activity D is then made a closely-continuous 
successor of activity A and B, in turn, is made a closely con- 
tinuous successor of D. Activity B is made an ordinary successor 
of activity C. Consider next the case illustrated in Fig. 2.4.34-2, 
wherein one activity cannot start until a second activity has 
started . 


© 0 

c 



Fig. 2.4.34-2 

Sample Representation of a General Temporal Relation Using 
Closely Continuous Successors 
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To represent this temporal relation, one need only introduce 
a single dummy event E. Then activity A is made a closely-con- 
tinuous successor of event E while activity B is made an ordinary 
successor . 

Although the closely-continuous successor concept provides a 
generalized network presentation of all of the general temporal 
relations, no simple heuristic procedure can be devised to sched- 
ule such a network. Long multibranch trees of closely-continuous 
successors of a given activity have to be scheduled before that 
activity itself can be scheduled. This considerably complicates 
the resource allocation logic perhaps to the point of diminishing 
returns. Any complications in a heuristic procedure must be 
justified by their results. Without establishing the utility of 
the relatively simple resource allocator for ordinary precedence 
networks, it seems pointless to build a vastly more complicated 
allocator for generalized precedence networks. Nonetheless, in 
Subsection 2.4.34.7, a proof is given that any general temporal 
relation can be moldeled using only ordinary and closely continuous 
successors. 

This module has the capability of scheduling .interfacing sub- 
networks. It assembles a user supplied master subnetwork and 
all of its interfacing subnetworks into a master network. All the 
activities of this master network are to be scheduled subject. to 
common resource availability levels. 
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A time-progressive heuristic program is used to obtain short, 
but not necessarily minimal, project durations. The heuristic 
employs a critical-path-based priority rule tempered by a modify- 
ing heuristic using contingency resource thresholds. By utiliz- 
ing late-start time as the priority value of each activity or 
event, a dynamic priority function is obtained that does not re- 
quire updating each time a new acticity is scheduled. This re- 
sults from the fact that the late-start date of an activity is 

independent of the actual scheduled start dates of any of its 

predecessor as long as none of them are delayed beyond its late- 

start date. Nonetheless, the late-start date does represent a 
good priority rule in terms of scheduling the least flexible 
activities first. That unscheduled activity with the earliest 
late-start date, other factors being equal, is the activity most 
likely to lengthen project duration beyond the critical-path value. 
The modifying heuristic is activated whenever an activity cannot 
be scheduled before its late-start date. The resource that pre- 
vents the scheduling of the activity is augmented by a user-input 
contingency threshold from the time the activity's predecessors 
were all completed until the activity is successfully scheduled. 

Finally, an option is provided for leveling the resource 
utilization profiles via a least squares heuristic after a tenta- 
tive initial schedule has been obtained from the late-start-date 
heuristic. The leveling procedure involves sequentially consider- 
ing the activities in order of latest scheduled finish. A weighted 
sum of squares of the resource profiles over time is then computed 
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for each activity for eac'fi 9 start date in its residual float.- 
That start date in the float interval is selected that will min- 
imize the weighted resource sum of squares . Two underlying 
principles motivate this heuristic procedure. First, by sequen- 
tially delaying activities considered, in order of their latest 
scheduled finish, the float of activities with earlier scheduled 
finishes can only be increased, thereby improving their subse- 
quent scheduling flexibility. Second, the weighted sum of squares 
of the resource profiles over time is decreased by reducing any 
jump in the utilization level of any resource from one time in- 
terval to the next. In fact, the unconstrained minimum sum of 
the squares is achieved when all the resource profiles are such 
that the utilization levels of any given resource in each time 
period by at most one unit. 

2.4.34.2 Modules Called 
NETWORK_ASSEMBLER 
RES0URCE_ALL0CAT0R 
RESOURCEJ.EVELER 

2.4.34.3 Module Input 

1) Network, Critical Path Data and Activity or Event Definitions 

( $ JOBSET ) 
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(MASTER 
SUBNET ' 


CO CO 
< < 
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2) Resource Definitions ($PR0FILES) 

JPROFILES 



3) Interfacing Event Definitions ($INTERFACE) 


IINTEFACE 



(EVENT 

IDENTIFIER) 


(IDENTIFIER OF 
CONTAINING SUBNET) 


4) Resource Leveling Option Indicator (LEVEL) 
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2.4.34.4 Module Output 


1) Resultant Project Schedule ($SCHEDULE) 

$SCHEDULE 

(JOB ID) ' 

FINISH 
E) 

2) Revised Resource Profiles ($PR0FILES) 

Same as for Module Input. 

2.4.34.5 Functional Description 

The HEURISTIC_SCHEDULING_PROCESSOR serves as an executive pro- 
cedure for controlling and coordinating the entire heuristic 
scheduling process. First the network must be built whose activ- 
ities are to be scheduled sharing the same common resources. By 
means of a call to the module NETWORK_ASSEMBLER, the user-specified 
master subnetwork and all of its interfacing subnetworks, as de- 
tailed in the interfacing event definitions, are assembled into 
the desired network. Next, the RES0URCE_ALL0CAT0R is called to 
schedule the activities of the network according to the minimum 
project duration heuristic procedure described above. Earliest 
late-start is used as the priority function for each activity. 
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2) Resource Definitions ($PR0FIL£S) 

$PR0FILES 



3) Interfacing Event Definitions ($INTERFACE) 


$INTEFACE 



(EVENT 

IDENTIFIER) 


(IDENTIFIER OF 
CONTAINING SUBNET) 


4) Resource Leveling Option Indicator (LEVEL) 
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2.4.34.4 Module Output 


1) Resultant Project Schedule ($SCHEDULE) 


$SCHEDULE 



m 


2) Revised Resource Profiles ($PR0FILES) 

Same as for Module Input. 1 
2.4.34.5 Functional Description 

The HEURISTIC_SCHEDULING_PROCESSOR serves as an executive pro- 
cedure for controlling and coordinating the entire heuristic 

/ 

scheduling process. First the network must be built whose activ- 
ities are to be scheduled sharing the same common resources. By 
means of a call to the module NETWORK_ASSEMBLER, the user-specif ied 
master subnetwork and all of its interfacing subnetworks, as de- 
tailed in the interfacing event definitions, are assembled into 
the desired network. Next, the RES0URCE_ALL0CAT0R is called to 
schedule the activities of the network according to the minimum 
project duration heuristic procedure described above. Earliest 
late-start is used as the priority function for each activity. 

2.4.34-10 
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If an activity is delayed beyond its late-start date because of a 
resource shortage, a modifying heuristic is invoked to increase 
the availability of the deficient resource by a user input con- 
tingency threshold. If the user does not request any resource 
leveling effort by leaving the leveling option indicator, LEVEL, 
unset, the heuristic scheduling process ends here, 'otherwise the 
module RESOURCE_LEVELER is called to heuristically reduce to a 
minimum the jumps in the resource utilization rate. The heuristic 
operates by considering the activities in order of latest sched- 
uled finish. The weighted sum of the resource profiles squares 
over time is then computed for each possible start time of the 
activity under consideration within its remaining total float. 

That start time is selected that minimizes the sum.. When all the 
activities have been considered for delay, the leveling effort 
is complete and the heuristic scheduling terminates. The simple 
macrologic for the processor is illustrated in the functional block 
diagram. More detailed information on the resource allocation 
and leveling heuristics can be found in the respective specifications 
for the modules, RES0URCE_ALL0CAT0R and RESOURCE_LEVELER. 
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2.4.34.6 Functional Block Diagram 


Form master network 
from master subnetwork 
and interfacing subnetworks, 
(Call NETWORK_ASSEMBLER) 


Tentatively schedule activities 
and events to heuristically 
minimize project duration while 
satisfying resource constraints. 
(Call RESOURCE ALLOCATOR) 
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all the original activities is maintained so that an ordinary 
predecessor or successor relation can be represented as usual. 
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2.4.35 GUB LP 


Bender’s algorithm makes use of the fact that for given values 
of x,. the problem reduces to an LP whose dual is independent of 
any particular choice of x. This enables an equivalent program 
with only one continuous variable to be formulated that can be 
solved as a subproblem to yield the overall integer solution. A 
brief description of this approach follows. 

2.4.36.6 Functional Block Diagram 
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2.4.38.6 Functional Block Diagram 
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2.4.38.7 Typical Applications 

Dual simplex is generally used as a submodule in other 
algorithms where the highly specialized advantages of the dual 
structure can be exploited. For example, dual simplex is used 
internally in the Benders' decomposition algorithm to solve for 
the extreme points and rays of the primal problem for a fixed 
value of the integer variables. The dual is used in this 
situation because then the constraint set is independent of any 
particular choice of the integer variables. (For more details, 
see the description of the Bender decomposition algorithm.) Dual 
simplex is also used in the Geofferion zero-one algorithm to 
solve for the strongest surrogate constraint. In both of these 
examples, dual simplex was used because in the process of solving 
the master program a subproblem was created that was particularly 
compatible with the dual algorithm. This is very typical of the 
situations in which the dual simplex module would be used. 

2.4.38.8 Implementation Considerations 

A more general dual algorithm could be developed, similar to 
that described in Ref 3 which handles type 1 variables directly. 

In this more general setting, the dual algorithm is not the same 
as the primal simplex applied to the dual problem. 
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